home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / cip / cip-minutes-90feb.txt < prev    next >
Text File  |  1993-02-17  |  7KB  |  145 lines
  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by Claudio Topolcic/BBN
  7.  
  8. MINUTES
  9.  
  10. The CO-IP Working Group met at the February 6-9 IETF Meeting at Florida
  11. State University.  The Tuesday sessions were a presentation and
  12. discussion on ATM networks by Guru Parulkar of Washington University.
  13. The Wednesday morning session was a discussion of the issues, questions,
  14. and experiments raised by a guaranteed service network.  The Wednesday
  15. afternoon session was canceled so that the working group members could
  16. attend the SMDS working group meeting.  Work on the ST-2 protocols
  17. specification was dropped due to insufficient time.
  18.  
  19. The ATM presentation consisted of roughly three parts:  a BISDN
  20. perspective, ATM networks, and SMDS. The Broadband Integrated Services
  21. Digital Network is intended to support voice and video, DS1/3, X.25, and
  22. Switched Multi-megabit Data Services, with the latter including
  23. connectionless 802.6.  The video services would include
  24. broadcast/permanent connections (e.g., cable TV), point-to-point
  25. connections, and switched connections, including conferencing.  Video
  26. rates include both NTSC (45 Mbit) and ATV (135 Mbit).  It is predicted
  27. that after 1995 it will be cheaper to run fiber to a home than to run
  28. copper.  The protocol stack consists of application supported by an
  29. adaptation layer (which would include segmentation and reassembly if
  30. required) over the ATM layer over a SONET physical layer.  SONET STS-3c
  31. consists of a 155.520 Mbit channel divided into 125 microsecond frames,
  32. with each frame containing 90 bytes of overhead and nine "channels" of
  33. 260 bytes each (the channels are not all byte aligned).
  34.  
  35. An ATM frame consists of a 5-byte header followed by 48 bytes of data.
  36. The header format isn't yet standardized, but would most likely consist
  37. of 28 bits of combined Virtual Path Identifier (VPI) and Virtual Channel
  38. Identifier (VCI), an 8-bit checksum, a 2-bit priority field, and a 2-bit
  39. type field.  A Virtual Path may inlude a number of Virtual Channels
  40. switched as a unit, so either the VPI or the VCI is used for cell
  41. forwarding on a hop-by-hop basis.  The boundary between the VPI and VCI
  42. might vary at different interfaces.  The VPI/VCI field might include
  43. other logical subfields, e.g., flow control information, etc.
  44.  
  45. The Adaptation layer consists of a convergence sublayer on top of a
  46. segmentation and reassembly sublayer.  The convergence sublayer wraps
  47. the padded application data with a header and trailer; the segmentation
  48. and reassembly sublayer segments the wrapped application data and adds
  49. its own header and trailer before passing each segment to the ATM layer.
  50.  
  51. The services provided by ATM include point-to-point, multicast, and
  52. dynamic multicast callees, a QOS (which would probably be a fixed delay
  53. and loss specification within a homogeneous network), naked (aka dark)
  54. cells which will not be reordered by the network, and a bandwidth
  55. requirement specification.  Bandwidth would be specified in terms of
  56.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64. mean, peak, and burst characteristics, with the actual nature of the
  65. latter still unspecified.  Bandwidth consumption would be limited to
  66. that requested.
  67.  
  68. With respect to CO-IP, there are two basic assumptions:  the Internet
  69. will be heterogeneous for some time, and that LANs will not be ATM
  70. networks in the forseeable future.  The conclusions were:  since
  71. applications may generate packets larger than cell size, transparent
  72. fragmentation and reassembly should be supperted, CO-IP parameters
  73. should be consistent with ATM (at least in the voice context where the
  74. packet size is small) and CO-IP should try to be consistent with ATM
  75. naked cells (to minimize as much as possible the adaptation layer), the
  76. working group should make concrete plans for CO-IP experiments across
  77. ATM based high-speed networks, and to identify work that has/is being
  78. done in the ATM community for use in the CO-IP subnet dependent layer.
  79.  
  80. Wednesday morning's session consisted of a discussion of CO-IP issues,
  81. questions, services and parameters.  Included were:  adherence to a
  82. schedule, blocking and delay, chokepoints, effect of linear topology
  83. problems and multi-hop paths, enforcement to meet performance
  84. requirements, fairness, reuse of unclaimed reserved bandwidth, combining
  85. best-effort and resource-reservation algorithms, throughput, and traffic
  86. characterizations.  The latter were described as duration relative to
  87. RTT (i.e., << 2 RTT,   2 RTT, and >> 2 RTT), flowrate (steady,
  88. compressed steady, bursty), and predictability (none, e.g., interactive,
  89. ASAP, e.g., mail, and scheduled, e.g., a conference).
  90.  
  91. A subset of the working group met Wednesday and Thursday evenings to
  92. discuss the practical details of future research collaboration.  We
  93. agreed that such cooperation was possible, and would result in increased
  94. results with an overall decrease in effort.  Since most participants
  95. felt most comfortable working with UNIX, we decided to adopt it as the
  96. experimental platform.  We agreed to implement a basic protocol
  97. infrastructure in the UNIX-based DRI experimental gateway for
  98. experiments across the DRI testbed.  MCHIP, ST-2, or other experimental
  99. protocols will be built on top of this infrastructure, and this would
  100. support experimentation and changes to the protocols.  It will be
  101. possible to replace the modules that implement different functions, such
  102. as resource management or failure detection, relatively easily.  By
  103. experimenting with them, we will gain practical experience in how
  104. different algorithms perform in various situations.  These initial
  105. implementations will evolve to a single better protocol as we
  106. incorporate the better approaches.  We are initially planning to
  107. implement a MCHIP gateway and host, and an ST-2 gateway and voice and
  108. video hosts.
  109.  
  110.  
  111. ATTENDEES
  112.  
  113.     Brim, Scott                    swb@devvax.tn.cornell.edu
  114.     Casner, Steve                  casner@isi.edu
  115.     Chatterjee, Samir              samir@nynexst.com
  116.  
  117.  
  118.                                    2
  119.  
  120.  
  121.  
  122.  
  123.  
  124.  
  125. Clapp, George                  meritec!clapp@bellcore.bellcore.com
  126. Easterday, Tom                 tom@nisca.ircc.ohio-state.edu
  127. Fidler, Mike                   ts0026@ohstvma.ircc.ohio-state.edu
  128. Fox, Richard                   sytek!rfox@sun.com
  129. Gerich, Elise                  epg@merit.edu
  130. Goldstein, Steve               goldstein@note.nsf.gov
  131. Lynn, Charles                  clynn@bbn.com
  132. McKenney, Paul E.              mckenney@sri.com
  133. Medin, Milo                    medin@nsipo.nasa.gov
  134. Parulkar, Guru                 guru@flora.wustl.edu
  135. Piscitello, David              dave@sabre.bellcore.com
  136. Ramakrishnan, K.K.             rama%erlang.dec.com@decwrl.dec.com
  137. Su, Zaw-Sing                   zsu@tsca.istc.sri.com
  138. Topolcic, Claudio              topolcic@bbn.com
  139. Wilder, Rick                   rick@gateway.mitre.org
  140. Yavatkar, Raj                  raj@ms.uky.edu
  141.  
  142.  
  143.  
  144.                                3
  145.